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SCALABLE VIRTUAL WORLD CHAT CLIENT -SERVER SYSTEM 

BACKGROUND OF THE INVENTION 
The present invention relates to the field of packet 
communications. More specifically, in one embodiment the 
invention provides an efficient communications network for 
client-server networks with large numbers of clients. 

A client -server network is a network where one or 
more servers are coupled to one or more clients over a 
communications channel. Typically, each server and each 
client is assigned an address so that each can determine which 
network messages are directed to it. While such a system may 
have only one server, it typically has many clients. A server 
object is one which waits for a request from a client object 
and then performs some service in response to the client 
request. A client is an object that makes the request. The 
designation of a particular object (computer hardware and/or 
software process) as a "server" object or a "client" object is 
not fixed. Thus, a given object can be a server for some • 
services and a client of other services. 

A typical computer network has one or more file and 
print servers with a number of clients, where the clients are 
the desktop computers or workstations of the computer users, 
all coupled to a high-speed network cable. Client-server 
communications in such a network are easily handled for 
several reasons. When clients are not all communicating with 
the server at once the server need not be designed to handle 
all the clients at one time. Another reason is that the 
network traffic is much less than the network capacity 
furthermore, the clients in a typical computer network need 
not necessarily be communicating in real-time with the server. 
However, where many client machines or processes are 
communicating with each other in real-time through the server, 
several problems arise . 
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For example, where a client -server system is used 
for real-time exchange of information, such as a distributed 
virtual reality network where users at client machines 
visually and aurally interact with other users at other client 
5 • machines, communication is much more difficult, especially 
where the information is high-bandwidth data such as audio 
streams, graphic images and image streams. One application of 
such a client -server system is for game playing, where the 
positions and actions of each user need to be communicated 

10 between all the players to inform each client of the state 

changes (position, actions, etc.) which occurred at the other 
clients. The server might maintain global state information 
and serve as a data server for the clients as they request 
visual, program and other data as the game progresses. 

15 Some game systems use a peer-to-peer architecture. 

In a peer-to-peer architecture, a copy of the data which is 
common to all clients is kept by the client and information 
which needs to pass between clients is broadcast over the 
network. This limits the number of clients which can be 

2 0 connected to the network, because the number of messages 

passing between clients is on the order of the square of the 
number of clients. With true broadcasting, one message is * 
sent and all clients listen for it, but not all network 
topologies can handle broadcasts. Where less than all the 

2 5 clients are participating in a game, for example, messages 

cannot be broadcast because there are clients which should not 
be receiving the broadcast message. Instead, the broadcast 
between the players is handled by generating one message, to 
each player client . 

3 0 This architecture is further limited where the 

network is not a dedicated network, but is an open network, 
such as the Internet. As used herein, the term "Internet" 
refers to the global inter-network of networks which 
communicates primarily using packets sent according to TCP/IP 
3 5 (Transport Control Protocol/Internet Protocol) standards well 
known in the art of computer intercommunication. With 
Internet communications, true broadcasting is not even 
possible because thfe network's extent is not known or fixed. 



Thus, messages to all players must be sent as separate 
messages. An additional problem with Internet communications 
is that packet delivery is not guaranteed nor is it even as 
reliable as a dedicated network. 

Therefore, what is needed is an efficient system for 
communication between many client systems over dedicated or 
open networks to provide graphical interaction between users 
operating the client systems. 

SUMMARY OF THE INVENTION 
The present invention provides a highly scalable 
architecture for a three-dimensional graphical, multi-user, 
interactive virtual world system. In a preferred embodiment a 
plurality of users interact in the three-dimensional, 
computer-generated graphical space where each user executes a 
client process to view a virtual world from the perspective of 
that user. The virtual world shows avatars representing the 
other users who are neighbors of the user viewing the virtual 
word. In order that the view can be updated to reflect the 
motion of the remote user's avatars, motion information is 
transmitted to a central server process which provides 
positions updates to client processes for neighbors of the • 
user at that client process. The client process also uses an 
environment database to determine which background objects to 
render as well as to limit the movement of the user's avatar. 

A further understanding of the nature and advantages 
of the inventions herein may be realized by reference to the 
remaining portions of the specification and the attached 
drawings . 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a client screen view in a virtual world 

system according to the present invention. 

FIG. 2 is a logical block diagram of the hardware 

elements of a virtual world system. 
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FIG. 3 is a block diagram of the elements of one 
embodiment of a virtual world system, showing two clients and 
one server . 

FIG. 4 is a more detailed block diagram of a client 
5 system according to one embodiment of the present invention. 
FIG. 5 is an illustration of an avatar. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 
Although the preferred embodiment of the present 

10 invention can be used in a variety of applications, as will be 
apparent after reading the below description, the preferred 
embodiment is described herein using the example of a 
client -server architecture for use in a virtual world "chat" 
system. In this chat, system, a user at each client system 

15 interacts with one or more other users at other client systems 
by inputting messages and sounds and by performing actions, 
where these messages and actions are seen and acted upon by 
other clients. FIG. 1 is an example of what such a client 
might display. 

.20 Each user interacts with a client system and the 

client system is networked to a virtual world server. The 
client system are desktop computers, terminals, dedicated game 
controllers, workstations, or similar devices which have 
graphical displays and user input devices. The term "client" 

25 generally refers to a client machine, system and/or process, 
but is also used to refer to the client and the user 
controlling the client. 

FIG. 1 is an illustration of a client screen display 
10 seen by one user in the chat system. Screen display 10 is 

30 shown with several stationary objects (wall, floor, ceiling 

and clickable object 13) and two "avatars" 18. Each avatar 18 
is a three dimensional figure chosen by a user to represent 
the user in the virtual world. Each avatar 18 optionally 
includes a label chosen by the user. In this example, two 

35 users are shown: "Paula" and "Ken", who have chosen the 

"robot" avatar and the penguin avatar, respectively. Each 
user interacts with a client machine (not shown) which 
produces a display Similar to screen display 10, but from the 



perspective of the avatar for that client/user. Screen 
display 10 is the view from the perspective of a third user, 
D, whose avatar is not shown since D's avatar is not within 
D's own view. Typically, a user cannot see his or her own 
5 • avatar unless the chat system allows "our of body" viewing or 
the avatar's image is reflected in a mirrored object in the 
virtual world. 

Each user is free to move his or her avatar around 
in the virtual world. In order that each user see the correct 
10 location of each of the other avatars, each client machine 
sends its current location, or changes in its current 
location, to the server and receives updated position 
information of the other clients. 

While FIG. 1 shows two avatars (and implies a 
L5 third), typically many more avatars will be present. A 

typical virtual world will also be more complex than a single 
room. The virtual world view shown in FIG. 1 is part of . a 
virtual world of several rooms and connecting hallways as 
indicated in a world map panel 19, and may include hundreds or 
20 users and their avatars. So that the virtual world is 

scalable to a large number of clients, the virtual world 
server must be much more discriminating as to what data is • 
provided to each clients. In the example of FIG. 1, although 
a status panel 17 indicates that six other avatars are 
25 present, many other avatars are in the room, but are filtered 
out for crowd control . 

FIG. 2 is a simplified block diagram of the physical 
architecture of the virtual world chat system. Several 
clients 2 0 are shown which correspond with the users 
30 controlling avatars 18 shown in screen display 10. These 

clients 20 interact with the virtual world server 22 as well 
as the other clients 2 0 over a network 24 which, in the 
specific embodiment discussed here, is a TCP/IP network such 
as the Internet. Typically, the link from the client is 
35 narrowband, such as 14.4 kbps (kilobits/second). 

Typically, but not always, each client 20 is 
implemented as a separate computer and one or more computer 
systems are used to/ implement virtual world server 22. As 



used here, the computer system could be a desktop computer as 
are well known in the art, which use CPU's available from 
Intel Corporation, Motorola, SUN Microsystems, Inc., 
International Business Machines (IBM) , or the like and are 
controlled by operation systems such as the Windows® program 
which runs under the MS-DOS operating system available from 
Microsoft Corporation, the Macintosh® O/S from Apple Computer, 
or the Unix® operating system available from a variety of 
vendors . Other suitable computer systems include notebook 
computers, palmtop computers, hand-held programmable computing 
devices, special purpose graphical game machines (e.g., those 
sold by Sony, SEGA, Nintendo, etc.), workstations, terminals, 
and the like. 

The virtual world chat system is described below 
with reference to at least two hypothetical users, A and B. 
Generally, the actions of the system are described with 
reference to the perspective of user A. It is to be 
understood that, where appropriate, what is said about user A 
applies to user B, and vice versa, and that the description 
below also holds for a system with more than two users (by 
having multiple users A and/or B) . Therefore, where an 
interaction between user A and user B is described, implied 
therein is that the interaction could take place just as well 
with users A and B having their roles reversed and could take 
place in the same manner between user A and user C, user D, 
etc . The architecture is described with reference to a system 
where each user is associated with their own client computer 
system separate from the network and servers, however a person 
of ordinary skill in the art of network configuration would 
understand, after reading this description, how to vary the 
architecture to fit other physical arrangements, such as 
multiple users per computer system or a system using more 
complex network routing structures than those shown here. A 
person of ordinary skill in the art of computer programming 
will also understand that where a process is described with 
reference to a client or server, that process could be a 
program executed by a CPU in that client or server system and 
the program could bfe stored in a permanent memory, such as a 



hard drive or read-only memory (ROM) , or in temporary memory, 
such as random access memory (RAM) . A person of ordinary 
skill in the art of computer programming will also understand 
how to store, modify and access data structures which are 
shown to be accessible by a client or server. 

Referring now to FIG. 3, a block diagram is shown of 
a world system 54 in which a user A, at a first client system 
60 (client A) , interacts with a user B at a second client 
system 60 (client B) via a server 61. Client system 60 
includes several databases, some of which are fixed and some 
of which are modifiable. Client system 60 also includes 
storage for program routines. Mechanisms for storing, reading 
and modifying data on computers such as client system 6 0 are 
well known in the art, as are methods and means for executing 
programs and displaying graphical results thereof. One such 
program executed by client system 60 is a graphical rendering 
engine which generates the user's view of the virtual world. 

Referring now to FIG. 4, a detailed block diagram of 
client 60 used by a user, A is shown. The other clients used 
by other users are similar to client 60. 

The various components of client 60 are controlled 
by CPU 100. A network packet processor 102 sends and receives 
packets over network connection 80. Incoming packets are 
passed to a network message processor 104 which routes the 
message, as appropriate to, a chat processor 106, a custom 
avatar images - database 108, a short object ID lookup table 
110, or a remote avatar position table 112. Outgoing packets 
are passed to network packet processor 102 by network message 
processor in response to messages received from chat processor 
106, short object ID lookup table 110 or a current avatar 
position register 114. 

Chat processor 106 receives messages which contain 
conversation (text and/or audio) or other data received from 
other users and sends out conversation or other data directed 
to other users. The particular outgoing conversation is 
provided to chat processor 106 by input devices 116, which 
might include a keyboard, microphones, digital video cameras, 
and the like. The Routing of the conversation message depends 
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on a selection by user A. User A can select to send a text 
message to everyone whose client is currently on line 
("broadcast"), to only those users whose avatars are "in 
range" of A' s avatar ("talk"), or to only a specific user 
5 ("whispering"). The conversation received by chat processor 
106 is typically received with an indication of the 
distribution of the conversation. For example, a text message 
might have a "whisper" label prepended to it. If the received 
conversation is audio, chat processor 10 6 routes it to an 

10 audio output device 118 . Audio output device 118 is a speaker 
coupled to a sound card, or the like, as is well known in the 
art of personal computer audio systems. If the received 
conversation is textual, it is routed to a rendering engine 
120 where the text is integrated into a graphical display 122. 

15 Alternatively, the text might be displayed in a region of 
display 122 distinct from a graphically rendered region. 

= Current avatar position register 114 contains the 

I current position and orientation of A' s avatar in the virtual 

world. This position is communicated to other clients via 

20 network message processor 104. The position stored in 
register 114 is updated in response to input from input 

= devices 116. For example, a mouse movement might be 

* interpreted as a change in the current position of A' s avatar. 

• Register 114 also provides the current position to rendering 
25 engine 120, to inform rendering engine 120 of the correct view 

point for rendering. 

Remote avatar position table 112 contains the 
current positions of the "in range" avatars near A' s avatar. 
Whether another avatar is in range is determined a "crowd 
3 0 control" function, which is needed in some cases to ensure 
that neither client 60 nor user A get overwhelmed by the 
crowds of avatars likely to occur in a popular virtual world. 

Server 61 maintains a variable, N, which sets the 
maximum number of other avatars A will see. Client 60 also 
35 maintains a variable, N' , which might be less than N, which 

indicates the maximum number of avatars client 6 0 wants to see 
and/or hear. The value of N' can be sent by client 0 to 
server 61. One reason for setting N' less than N is where 



client 60 is executed by a computer with less computing power 
than an average machine and tracking N avatars would make 
processing and rendering of the virtual world too slow. Once 
the number of avatars to be shown is determined, server 61 
5 determines which N avatars are closest to A's avatar, based on 
which room of the world A' s avatar is in and the coordinates 
of the avatars. This process is explained in further detail 
below. If there are less than N avatars in a room which does 
not have open doors or transparent walls and client 6 0 has not 
10 limited the view to less than N avatars, A will see all the 
avatars in the room. Those avatars are thus "neighboring" 
which means that client 6 0 will display them. 

Generally, the limit set by server 61 of N avatars 
and the limit set by client 60 of N' avatars control how many 
■15 avatars A sees. If server 61 sets a very high value for N, 
then the limit set by client 60 is the only controlling 
factor. In some cases, the definition of "neighboring" might 
be controlled by other factors besides proximity. For 
example, the virtual world might have a video telephone object 
2 0 where A can speak with and see a remote avatar. Also, where N 
s or more unfriendly avatars are in close proximity to A' s 

I avatar and they persist in following A's avatar, A will not- be 

"= able to see or communicate with other, friendly avatars. To 

I prevent this problem, user A might have a way to filter out 

25 avatars on other variables in addition to proximity, such as 
user ID. 

In any case, remote avatar position table 112 
contains an entry for each neighboring avatar. That entry 
indicates where the remote avatar is (its position) , its 

30 orientation, a pointer to an avatar image, and possible other 
data about the avatar such as its user's ID and name. The 
position of the avatar is needed for rendering the avatar in 
the correct place. Where N' is less than N, the client also 
uses position data to select N' avatars from the N avatars 

35 provided by the server. The orientation is needed for 

rendering because the avatar images are three-dimensional and 
look different (in most cases) from different angles. The 
pointer to an avatai- image is an index into a table of 
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preselected avatar images, fixed avatar image database 71, or 
custom avatar images database 108. In a simple embodiment, 
each avatar image comprises M panels (where M is greater than 
two with eight being a suitable number) and the i-th panel is 
5 • the view of the avatar at an angle of 360*i/M degrees. Custom 
avatar images are created by individual users and sent out 
over network connection 80 to other clients 60 which are 
neighbors of the custom avatar user. 

Short object ID lookup table 110 is used to make 

10 communications over network connection 80 more efficient. 

Instead of fully specifying an object, such as a particular 
panel in a particular room of a world avatar, a message is 
sent from server 61 associating an object's full 
identification with a short code. These associations are 

15 stored in short object ID lookup table 110. In addition to 
specifying avatars, the short object ID'S can be used to 
identify other objects, such as a panel in a particular room. 

Short object ID lookup table 110 might also store 
purely local associations. Although not shown in FIG. 4, it 

2 0 is to be understood that connections are present between 

elements shown and CPU 100 as needed to perform the operations 
described herein. For example, an unshown connection would 
exist between CPU 100 and short object ID lookup table 110 to 
add, modify and delete local short object ID associations. 

25 Similarly, CPU 100 has unshown connections to rendering engine 
120, current avatar position register 114 and the like. 

Client 60 includes a rooms database 70, which 
describes the rooms in the virtual world and the 
interconnecting passageways. A room need not be an actual 

30 room with four walls, a floor and a ceiling, but might be 

simply a logical open space with constraints on where a user 
can move his or her avatar. CPU 100, or a specific motion 
control process, limits the motion of an avatar, 
notwithstanding commands from input devices 116 to do so, to 

3 5 obey the constraints indicated in rooms database 70. A user 

may direct his or her avatar through a doorway between two 
rooms, and if provided in the virtual world, may teleport from 
one room to another! 



11 

Client 60 also includes an audio 
compressor/decompressor 124 and a graphics 
compressor/decompressor 126. These allow for efficient 
transport of audio and graphics data over network connection 
5 ■ 80 . 

In operation, client 60 starts a virtual world 
session with user A selecting an avatar from fixed avatar 
image database 71 or generating a custom avatar image. In 
practice, custom avatar image database 108 might be combined 

10 with fixed avatar image database 71 into a modifiable avatar 
image database. In either case, user A selects an avatar 
image and a pointer to the selected image is stored in current 
avatar position register 114. The pointer is also 
communicated to server 61 via network connection 80 . Client 

15 60 also sends server 61 the current position and orientation 
of A's avatar, which is typically fixed during the 
initialization of register 114 to be the same position and 
orientation each time. 

Rooms database 70 in a fixed virtual world is 

20 provided to the user with the software required to instantiate 
the client. Rooms database 70 specifies a list of rooms, 
including walls, doors and other connecting passageways. 
Client 60 uses the locations of walls and other objects to 
determine how A's avatar's position is constrained. Rooms 

25 database 70 also contains the texture maps used to texture the 
walls and other objects. Avatar database 71 specifies the 
bitmaps used to render various predefined avatars provided 
with the client system. Using rooms database 70 and the 
locations, tags and images of all the neighboring avatars, 

3 0 then a view of objects and other avatars in the virtual world 
can be rendered using the room primitives database and the 
avatar primitives database. 

Instead of storing all the information needed for 
rendering each room separately, a primitives database can be 

35 incorporated as part of rooms database 70. The entries in 
this primitives database describe how to render an object 
(e.g., wall, hill, tree, light, door, window, mirror, sign, 
floor, road) . With) the mirrored primitive, the world is not 
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actually mirrored, just the avatar is. This is done by- 
mapping the avatar to another location on the other side of 
the mirrored surface and making the mirror transparent . This 
will be particularly useful where custom avatars are created, 
5 • or where interaction with the environment changes the look of 
the avatar (shark bites off arm, etc.) . 

The typical object is inactive, in that its only 
effect is being viewed. Some objects cause an action to occur 
when the user clicks on the object, while some objects just 

10 take an action when their activating condition occurs. An 
example of the former is the clickable objects 13 shown in 
FIG. 1 which brings up a help screen. An example of the latter 
is the escalator object. When a user's avatar enters the 
escalator's zone of control, the avatar's location is changed 

15 by the escalator object automatically (like a real escalator) . 

The avatars in fixed avatar image database 71 or 
custom avatar images database 108 contain entries which are 
used to render the avatars . A typical entry in the database 
comprises N two-dimensional panels, where the i-th panel is 

20 the view of the avatar from an angle of 360 * i/N degrees. 
Each entry includes a tag used to specify the avatar. 

In rendering a view, client 6 0 requests the 
locations, orientations and avatar image pointers of 

25 neighboring remote avatars from server 61 and the server's 
responses are stored in remote avatar position table 112. 
Server 61 might also respond with entries for short object ID 
lookup table 110 . Alternatively, the updates can be done 
asynchronously, with server 61 sending periodic updates in 

3 0 response to a client request or automatically without request. 

Rendering engine 120 then reads register 114, remote 
avatar position table 112, rooms database 70 and avatar image 
databases as required, and rendering engine 12 0 renders a view 
of the virtual world from the view point (position and 

35 orientation) of A' s avatar. As input devices 116 indicate 

motion, the contents of register 114 are updated and rendering 
engine 120 re -renders the view. Rendering engine 12 0 might 
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periodically update the view, or it may only update the view 
upon movement of either A' s avatar or remote avatars. 

Chat processor 106 accepts chat instructions from 
user A via input devices 116 and sends conversation messages 
to server 61 for distribution to the appropriate remote 
clients. If chat processor 106 xeceives chat messages, it 
either routes them to audio output device 118 or to rendering 
engine 120 for display. 

Input devices 116 supply various inputs from the 
user to signal motion. To make movement easier and more 
natural, client 6 0 performs several unique operations. One 
such operation is "squared forward movement" which makes it 
easier for the user to move straight. Unlike ordinary mouse 
movements, where one mouse tick forward results in an avatar 
movement forward one unit and one mouse tick to the left or 
right results in side movement of one unit, squared forward 
movement squares the forward/backward ticks or takes the 
square root of the sideways ticks or divides by the number of 
forward/backward ticks. For example, if the user moves the 
mouse F mouse ticks forward, the avatar moves F screen units 
forward, whereas if the user moves the mouse F mouse units 
forward and L mouse units to the left, the avatar moves F - 
units forward and L/F screen units to the left. For covering 
non-linear distances, (F,L) mouse units {i.e., F forward, L to 
the side) might translate to (F 2 ,L) screen units. 

As mentioned above, user input could also be used to 
signal a desire for interaction with the environment (e.g. 
clicking on a clickable object) . User input could also be 
used to signal for a viewpoint change (e.g. head rotation 
without the avatar moving, chat inputs and login/logout 
inputs . 

In summary, client 60 provides an efficient way to 
display a virtual, graphical, three-dimensional world in which 
a user interacts with other users by manipulating the 
positions of his or her avatar and sends chat messages to 
other users. 

Network connection 8 0 will now be further described. 
Commonly, network connection 80 is a TCP/IP network connection 
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between client 60 and server 61. This connection stays open 
as long as client 6 0 is logged in. This connection might be 
over a dedicated line from client 60, or might be a SLIP/PPP 
connection as is well known in the art of network connection. 

The network messages which pass over network 
connection 80 between client 60 and server 61 are described 
immediately below briefly, with a more detailed description in 
Appendix A. Three main protocols exist for messaging between 
client 60 and server 61: 1) A control protocol, 2) a document 
protocol, and 3) a stream protocol. The control protocol is 
used to pass position updates and state changes back and forth 
between client 60 and server 61. The control protocol works 
with a very low bandwidth connection. 

The document protocol is used between client 6 0 and 
server 61 to download documents (text, graphics, sound, etc.) 
based on Uniform Resource Locators (URLs) . This protocol is a 
subset of the well-known HTTP (Hyper-Text Transport Protocol) . 
This protocol is used relatively sparingly, and thus bandwidth 
is not as much of a concern as it is with the control 
protocol. In the document protocol, client 60 sends a 
document request specifying the document's URL and server 61 
returns a copy of the specified document or returns an error 

(the URL was malformed, the requested URL was not found, 

etc . ) . 

The stream protocol is used to transfer real-time 
video and audio data between client 60 and server 61. 
Bandwidth is not as much a concern here as it is with the 
control protocol. 

Each room, object, and user in a virtual world is 
uniquely identified by a string name and/or numerical 
identifier. For efficient communications, string names are 
not passed with each message between client 60 and server 61, 
but are sent once, if needed, and stored in short object ID 
lookup table 110. Thereafter, each message referring to an 
object or a user need only refer to the short object ID which, 
for 256 or less objects, is only an 8 -bit value. Rooms are 
identified by a unique numerical value contained in two bytes 
(16 bits) . } 
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The control protocol is used by client 6 0 to report 
the location and state information, such a "on" and "off" 
states for a light object or other properties, for user A to 
server 61 and is used by server 61 to send updates to client 
60 for remote avatar position table 112 and updates of 
characteristics of other objects in the virtual world 
environment . Server 61 also uses the control protocol to 
update client 61 on which avatars are in range of A' s avatar. 
To allow for piecemeal upgrading of a virtual world system, 
client 60 will not err upon receipt of a message it does. not 
understand, but will ignore such as message, as it is likely 
to be a message for a later version of client 60. 

Each message is formed into a control packet and 
control packets assume a very brief form so that many packets 
can be communicated quickly over a narrowband channel . These 
control packets are not to be confused with TCP/IP or UDP 
packets, although a control packet might be communicated in 
one or more TCP/IP or UDP packets or more than one control 
packet might be communicated in one TCP/IP packet.. The 
format of a control packet is shown in Table 1 . 



TABLE 1. 



FIELD 
PktSize 



ObjID 



SIZE 
UInt8 



UInt8 (ShortObjID) 
Ostring (LongObjID) 

Command UInt8 + arguments 



DESCRIPTION 

Number of bytes in the control 
packet (including Pktsize byte) 

Identifies the object to which 
the command is directed 

Describes what to do with the 
obj ect 



"UInt8" is an 8 -bit unsigned integer. "Ostring" is a byte 
containing zero (indicating that a long object identifier is 
to follow) followed, by a string (which is defined to be a byte 
containing the size 1 ' of the string followed by the characters 
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of the string) . Each control packet contains one command or 
one set of combined commands. The Obj ID field is one of two 
formats: either a ShortOb j ID (0 to 255) or a LongObjID (a 
string) . The Obj ID field determines which object in the 
5 • client's world will handle the command. Several ShortObjID 
values are preassigned as shown in Table 2 . 



TABLE 2 . 



ShortObi ID Object 

0 A short Obj ID of 0 indicates 
that a Long Obj ID follows 

1 The Client's Avatar 

254 CO - Combine Object 

255 PO - Protocol Object 

The other ShortObjID values are assigned by server 
61 to represent objects in the virtual world. These 
assignments are communicated to client 60 in a control packet 
as explained below. The assignments are stored by client 60 
in short object ID lookup table 110. The ShortObjID 
references are shorthand for an object which can also be 
referenced by a LongObjID. 

When commands are directed at the CO object 
( ShortOb j ID=254) , those commands are interpreted as a set of 
more than one command. When commands are directed at the PO 
object, the command applies to the communications process 
itself. For example, the REGOBJIDCMD command, which registers 
an association between a ShortObjID and a LongObjID, is 
directed at the PO object. Upon receipt of this command, 
client 60 registers the association in the short object ID 
lookup table . 

A command takes the form of a command type, which is 
a number between 0 and 255, followed by a string of arguments 
as needed by the particular command. 
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The CO object is the recipient of sets of commands. 
One use of a set of commands is to update the positions of 
several avatars without requiring a separate control packet 
for each avatar, thus further saving network bandwidth. The 
5 • form of the command is exemplified by the following command to 
move objects 2 and 4 (objects 2 and 4 are remote avatars) : 

S>C CO SHORTLOCCMD [2 -10 -20 -90] [4 0 0 90] 

10 In the above control packet, "S>C" indicates the 

direction of the packet (from server to client) , CO is the 
object, SHORTLOCCMD is the command type, and the command type 
is followed by three abbreviated commands. The above control 
packet requires only fifteen bytes: one for packet size (not 

15 shown) , one for the CO object ID, one for the command type and 
twelve for the three abbreviated commands. Note that the 
"S>C" indicator is not part of the control packet. The 
position of the boundaries between commands (indicated above 
with brackets, which are not actually communicated) is 

2 0 inferred from the fact that the SHORTLOCCMD command type 

requires four byte-wide arguments. Each abbreviated command 
in a command set is the same size, for easy parsing of the • 
commands by the CO. Examples of abbreviated commands for 
which a CO command is useful are the Teleport, Appear, 

25 Disappear, and ShortLocation commands. These commands, and 
other commands, are described in more detail in Appendix A. 
Appendix A also shows the one byte representation of 
SHORTLOCCMD as well as the one byte representations of other 
command types. The contents of control packets described 

30 herein are shown in a readable form, however when transmitted 
over network connection 80, the control packets are compacted 
using the values shown in Appendix A. 

The following examples show various uses of control 
35 packets. In the following sequences, a line beginning with 
"S>C" denotes a control packet sent from server 61 to client 
60, which operates user A' s avatar and interacts with user A. 
Similarly, a line beginning with "C>S" denotes a control 
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packet sent from client 60 to server 61. Note that all of the 
lines shown below omit the packet size, which is assumed to be 
present at the start of the control packet, and that all of 
the lines are shown in readable format, not the compact, 
efficient format discussed above and shown in Appendix A. 

The following is a control packet for associating 
ShortObj IDs with Long Object names: 

S>C PO REGOBJIDCMD "Maclen" 5 

Server 61 determines what short object ID (ShortObj ID)' to 
use for a given object. With four pre-allocated Short Obj ID 
values, server 61 can set up 2 52 other ID values. In the 
above command, the object whose long name is "Maclen" is 
assigned the ShortObj ID of 5. This association is stored by 
client 60 in short object ID lookup table 110. The first two 
fields of the above command line, "PO" and "REGOBJIDCMD" 
indicate that the protocol object (PO) is to handle the 
command and indicate the command type (REGOBJIDCMD) . The 
actual binary for the command is, in hexadecimal (except for 
the string) : 

S>C FF 0D 06 Maclen 05 

The following is a control packet containing a chat 

message : 

C>S CLIENT TEXTCMD " " "Kyle, How is the weather?" 

The Obj ID field is set to CLIENT. The field following the 
command type (TEXCMD) is unused in a text command from client 
to server. Server 61 will indicate the proper Ob j ID of user 
A' s avatar when sending this message back out to the remote 
clients who will receive this chat message. Thus, server 61 
might respond to the above command by sending out the 
following control packet to the remote clients (assuming user 
A is named "Judy") : > 
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S>C CLIENT TEXTCMD "Judy" "Kyle, How is the weather?" 

Of course, the text "Judy" need not be sent. If a short 
object identifier has been registered with the client for 
Judy's avatar, only the ShortObj ID for "Judy" need be sent. 
User A may also whisper a command to a single user who may or 
may not be in the same room, or even in the same virtual 
world. For example: 

C>S CLIENT WHISPERCMD "Kyle" "Kyle, How are you?" 

Server 61 will route this message directly to the recipient 
user. On the recipient client, the control packet for the 
message will arrive with the ObjID of the sender (just like a 
TEXTCMD) , however, that client will know that it is a private 
message because of the command type. The remote client 
receives the following control packet from server 61: 

S>C CLIENT WHISPERCMD "Judy" "Kyle, How are you?" 

Other examples of control packets, such as those for entering 
and exiting sessions and applications, are shown in Appendix 
B. For state and property changes, objects have two kinds of 
attribute variables. The first kind of attribute values are 
"states" which represent boolean values. The second kind of 
attribute values are called "properties" and may contain any 
kind of information. Client 60 reports local attribute 
changes to server 61 as needed and server 61 reports to client 
6 0 the attribute changes which might affect client 60. A 
different command is used for each kind of attribute, as shown 
in Appendix B . 

From user A' s point of view, avatars will appear and 
disappear from A' s view in a number of circumstances. For 
example, avatars enter and leave rooms and move in and out of 
visual range (as handled by crowd control rules described 
below) . Avatars also teleport from room to room, which is 
different than moving in and out of rooms. Client 60 will 
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send server 61 the following location and/or room change 
commands under the circumstances indicated: 



- LOCATIONCMD: normal movement of A' s avatar 
5 - ROOMCHGCMD : changing rooms by walking 

- TELEPORTCMD : changing rooms and/or location by 
teleporting 

- TELEPORTCMD, ExitType=0 : entering the application 

- TELEPORTCMD, EntryType=0 : exiting the application. 

10 

When other, remote clients take such actions, server 61 sends 
control packets to client 60, such as: 

- TELEPORTCMD: remote avatar teleported (EntryType or 

L5 ExitType may be 0 if the exit or entry was not visible to user 
A) 

- DISAPPEARACTORCMD : remote avatar was previously visible 
(in range) , but is now invisible (out of range) due to normal 
(non-teleport) movement including having walked out of the 

2 0 room 

- APPEARACTORCMD : remote avatar was not visible, and is 
now visible (command includes the remote avatar's Location and 
Room) 

- SHORTLOCCMD or LONGLOCCMD: remote avatar was visible 
25 before, and is still now, but has moved. 



Two methods exist for updating the position of an 
actor (avatar) . The LONGLOCCMD method uses full absolute 

3 0 position (X, Y, and Z) and orientation. The SHORTLOCCMD only 
updates the X and Y coordinates and the orientation. In 
addition, the short method limits the change in position to 
plus or minus 127 in the X and/or Y coordinates and/or +/- 127 
in the orientation. Client 6 0 sends a LONGLOCCMD to server 61 

35 to update the client's position. Whenever possible, server 61 
uses the combined SHORTLOCCMD to update all of the visible 
avatars at once. If an avatar has moved too great a distance, 



21 

or has moved in the Z direction, server 61 then uses a 
LONGLOCCMD for that avatar. 

The following is an example of a control packet sent 
from client 60 to server 61 to update user A's location: 

5 • 

C>S CLIENT LONGLOCCMD 2134 287 7199 14003 

In the binary (given in hex), this is: 

10 C>S 01 01 0856 011F 1C1F 36B3 

Note that bytes are two digits and shorts (16 bits) are four 
digits. They are separated by spaces here for clarity. The 
actual packet would contain no spaces. 
L5 The Server often uses the combined short location 

update command. This command concatenates several 
ShortLocationCommands . Rather than sending a command to each 
of the objects in question, a single combined command is sent 
to the combine object (CO) . This object takes the command and 

2 0 applies it to a list of truncated commands. The truncated 

commands contain a ShortObjID reference to the object to be 
moved and a change in the X and Y positions and orientation-. 
If server 61 wants to update the positions of objects 56, 42 
and 193, it would send the following: 

25 

S>C CO SHORTLOCCMD 56 -4 6 -10 42 21 3 -50 193 -3 -21 10 

This command can contain a variable number of subcommands . 
Each subcommand is of fixed length so that the CO can find the 
30 length of it from a table check or other quick lookup method. 
The binary form of this command is: 

S>C FE 04 38 FC 06 F6 2A 15 03 CD CI FD EB 10 

3 5 When user A changes rooms by walking through a door, 

a RoomChange Command control packet is sent by client 6 0 to 
server 61 to inform server 61 that the room change occurred. 
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The command specifies the new room and location for user -A' s 
avatar as follows : 

C>S CLIENT ROOMCHNGCMD 01 25 1200 150 180 

5 • 

The first argument is the ObjID of the avatar that 
is leaving the room, the second argument is the command type 
(room change) , and the third argument is the room that the 
avatar is entering. The next three arguments are the X, Y and 

10 Z positions at which to place the avatar in the room. The 
last argument is the direction the actor is facing 
(orientation) . Note that the first argument is always the 
ObjID for the local avatar, CLIENT = 1. 

When user A teleports from one room to another, the 

15 Teleport Command is sent by client 60 to server 61 to inform 
server 61 that the teleport occurred. The method of leaving 
the room and entering the new one is sent to server 61. This 
allows server 61 to inform other clients to display explosions 
or clouds, smoke or other indications of the teleportation 

2 0 appearance /disappearance of the avatar. The teleport command 
is as follows: 

C>S CLIENT TELE PORTCMD 01 02 02 25 1200 150 180 

25 The first argument is the ObjID of the avatar that is 
teleporting, the second argument is the command type 
(teleport) , and the third argument is the room that the avatar 
is entering. The next two arguments are the leaving method 
and the entering method respectively. The next three 

30 arguments are the X, Y and Z positions at which to place the 
actor in the room. The last argument is the direction the 
actor is facing (orientation) . Note that the first argument 
is always the ObjID for the local avatar, CLIENT = 1. 

Client 60 is responsible for implementing some sort 

35 of caching mechanism for actors. When client 60 receives a 
Teleport Command or AppearCommand for an avatar that is 
appearing, it must first determine if it currently has 
information for the } specif ied object cached. If not, client 
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60 can issue a request for any needed information pertaining 
to the object. Suppose client 60 receives the following 
command specifying that "Mitra" has arrived at room 15: 

5 - S>C "Mitra" TELEPORTCMD 15330000 

If client 60 does not have an entry cached for this object 
("Mitra"), or if the entry is dated, a request may be made for 
pertinent information (here, the long object ID is used since 
10 client 60 does not have the short object Id association for 
this object) : 

C>3 "Mitra" PROPREQCMD VAR_BITMAP 

15 Server 61 will respond with a PropertyCommand as necessary to 
communicate the required information. An example of pertinent 
information above is a request for the avatar bitmap to use to 
represent mitra. 

20 Crowd control is one of the tougher problems solved 

by the present system. Crowd control is handled using a 
number of commands. In a typical situation, the number of • 
avatars in a room is too large to be handled by client 6 0 and 
displayed on display 122. The maximum number of avatars, N, 

25 is determined by server 61, but might also be determined for 
each client . 

Server 61 addresses this problem by maintaining, for 
each user, a list of the N avatars nearest to the location of 
that user's avatar. This list may be managed by the server in 

30 any of a number of ways. When an avatar (B, for example) is 
removed from another user's (C, for example) list because 
avatar B can no longer be seen by C (i.e., B is no longer one 
of the N nearest avatars) , Server 61 sends a DISAPPEARACTORCMD 
to the object for avatar B on client C. This occurs as a 

3 5 consequence of client B changing rooms with a ROOMCHANGECMD or 
TELEPORTCMD, or due to crowd control. 

Client 60 does not necessarily delete an entry from 
remote avatar lookup table 112 or short object ID lookup table 



110 if a remote avatar disappears, but just marks it as being 
non-visible. In some cases, a user can see another user's 
avatar, but that other user cannot see the first user's 
avatar. In other words, visibility is not symmetric. 
However, chat exchange is symmetric, i.e., a user can only 
talk to those who can talk to the user. 

When A' s avatar is to be added to user B's lists 
when A becomes visible to B by reason of movement, room 
change, crowd control, or the like, server 61 (more precisely 
the protocol object PO on server 61) sends a REGOBJIDCMD 
control packet to the PO of B's client 60 and B's client 60 
will add the association of A' s avatar with a short object ID 
to short object ID lookup table 110. Server 61 also sends an 
APPEARACTORCMD control packet to A's client giving the room 
and location of B . If A's client 60 does not have the 
appropriate information cached for B, A's client 60 sends a 
P rope rtyRequest Command control packet to server 61 asking for 
the properties of B, such as the bitmap to use to display B's 
avatar. Server 61 will return the requested information, 
which it might need to obtain from B's client 60. For 
example, the control packet: 

PROPREQCMD VAR_B I TMAP 

might be used. Whenever possible, location updates from 
server 61 will be sent as SHORTLOCCMD control packets 
addressed to the remote avatar using its ShortObjld and the 
DisappearActorCommands , AppearActorCommands , and 
Teleport Commands used to update client 6 0 on the status of 
visible remote avatars will be combined as described for the 
Short LocationCommands . 

The server 61 shown in FIG. 3 will now be described. 
Server 61 comprises generally a network layer 62, protocol 
objects 63, user objects 64, room objects 65. In an object 
oriented software embodiment of the invention, each of these 
objects and layers are implemented as objects with their 
specific methods, data structures and interfaces. Where 
server 61 is implemented on a hardware running the Unix 
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operating system, these objects might be objects in a single 
process or multiple processes. Where server 61 is implemented 
on hardware running the Windows (tm) operating system alone or 
in combination with the MS-DOS operating system or the like, 
the layers and objects might be implemented as OLE (Object 
Linking and Embedding) objects. 

One protocol object 63 and one user object 64 are 
instantiated for each user who logs into server 61. Network 
layers 62 accepts TCP/IP connections from clients 60. A 
socket is opened and command buffers are allocated for each 
client 60. Network layer 62 is responsible for instantiating 
a protocol object 63 for each TCP/IP socket established. This 
layer handles the sending and receiving of packets, such as 
control packets, document packets and stream packets, over the 
network. All sockets are examined by server 61 on a periodic 
basis; completed control packets received from a client 6 0 are 
processed by server 61, and outgoing control packets to a 
client 60 which are pending are sent. 

Protocol object 63 handles translation of internal 
messages to and from the cryptic and compressed form of the 
control packets which are sent over network connection 80, as 
explained in Appendices A and B. Protocol object 63 handles 
all session initialization and authentication for its client 
60, and is responsible for instantiating a user object 64 for 
authenticated users. 

User object 64 tracks ' the location of its user's 
avatar, which includes at least the room in which the user is 
located, the user's coordinates in the room and the user's 
orientation in that room. User object 64 also maintains a 
list of the N nearest neighboring remote avatars (i.e., 
avatars other than the avatar for the user object's 
client/user) in the room. This list is used to notify the 
user object's client 60 regarding changes in the N closest 
remote avatars and their locations in the room. The list is 
also used in disseminating text typed by the user to only 
those users nearest him or her in the room. This process of 
notifying client 60 of only the N nearest neighbors is handled 
as part of crowd control . 
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One room object 65 is instantiated for each room in 
rooms database 70 and the instantiation is done when server 61 
is initialized. Alternatively, room objects can be 
instantiated as they are needed. As explained above, the term 
"room" is not limited to a visualization of a typical room, 
but covers any region of the virtual world which could be 
grouped together, such as the underwater portion of a lake, a 
valley, or a collection of streets. The room object for a 
specific room maintains a list of the users currently located 
in that room. Room object 65 periodically analyzes the 
positions of all users in the room using a cell-based 
algorithm, and sends a message to each user object 64 
corresponding to those users in the room, where the message 
notifies the user object of its user's N nearest neighbors. 

Periodically, the locations of the users in each 
room are examined and a square two-dimensional bounding box is 
placed around the users' current locations in the room. This 
square bounding box is then subdivided into a set of square 
cells. Each user is placed in exactly one square. Then, for 
each user, the cells are scanned in an outwardly expanding 
wave beginning with the cell containing the current user of 
interest, until at least N neighbors of that user are found. 
If more than N are found, the list of neighbors is sorted, and 
the closest N are taken. 

One or more world object 66 may be instantiated at 
the time server 61 is started. The world object maintains a 
list of all the users currently in the world and communicates 
with their user objects 64. The world object also maintains a 
list of all the rooms in the world and communicates with the 
room objects 65 for those rooms. The world object 
periodically initiates the analysis of user positions in each 
room and subsequent updating of avatar information to clients 
(60) . In addition, the world object periodically initiates 
the collection of statistics on usage (for billing, study of 
which rooms are most popular, security logs, etc.) which are 
logged to a file. 

Server 61 also has a rooms/world database 92 which 
is similar to the rooms/world database 70 in client 60. 



Server 61 does not need the primitives databases because there 
is no display needed at the server. Server 61 does, however, 
include a user state database 90, which maintains state 
information on each user, such as address, log- in time, 
accounting information, etc. 

Several interconnections are shown in FIG. 3. Path 
81 between a protocol object 63 and a user object 64 carries 
messages between a client 60 and the user object 64 
representing that client (before or after having been 
translated by a protocol object 63) . Typical messages from 
the client to the user object include: 

- Move my avatar to (x, y, z, orientation) 

- Send a text message to all neighboring remote avatars 

Typical messages from the user object to the client 

are : 

- User X teleported into your view at (x, y, z, orient.) 

- User Z has just left your view 

- User W has moved to (x, y, z, orientation) 

- Here is text from user Y 

- Here is private text (whispered) from user A 

The path 82 between a client 60 and a user object 64 
other than its own user object 64 is used to send whispers 
from user to user. Path 83 is used for internal messages sent 
directly between user objects 64. Messages taking this path 
typically go from a given user to those users who are among 
its N nearest neighbors. Typical messages include: 

- Here is text I have typed 

- I have just teleported to a given room and location 

- I have changed my state (logged in, logged out, etc.) 

- I have changed one or more of my properties 

Path 84 is used for messages between a user object 
64 and a room object 65. User objects 64 communicate their 
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location to the room 65 they are currently in. Periodically, 
the room object will notify the user object of the identities 
and locations of the users' N nearest neighbors. Messages 
from the user object to the room include: 

- I have just teleported either into or out of this room 

- I have just entered this room 

- I have just left this room 

- My new location in this room is (x, y, z, orientation) 

The only message that passes from the room object to 
a user object is the one that notifies the user of its N 
nearest neighbors. Path 85 is used for communications between 
protocol objects and world object 66. Protocol object 63 can 
query world object 66 regarding the memory address (or 
functional call handle) of the user object 64 representing a 
given user in the system. This is the method that is used to 
send a whisper message directly from the protocol object to 
the recipient user object. Path 86 is used for communications 
between user object 64 and world object 66 to query the world 
object regarding the memory address or function call handle of 
the room object 65 representing a given room in the world. * 
This is required when a user is changing rooms. FIG. 5 is an 
illustration of the penguin avatar rotated to various angles. 

The above description is illustrative and not 
restrictive. Many variations of the invention will become 
apparent to those of skill in the art upon review of this 
disclosure. The scope of the invention should, therefore, be 
determined not with reference to the above description, but 
instead should be determined with reference to the appended 
claims along with their full scope of equivalents . 
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Appendix A - Client/Server Control Protocol Commands (in BNF) 



Valid CommandTypes are integers between 0 and 2 55. Several of 
these are shown below as part of the BNF (Backus-Nauer Format) description 
of the command structures. Per convention, words starting with uppercase 
characters are non- terminals while those in quotes or in lowercase are 
terminal literals. 



Basics 
a | b = 
" abc " = 



Either a or b. 

The exact string of characters a, b and c in the order shown. 
= One or more occurrences of a. 
= Zero or more occurrences of a. 

= A number 10. In the ASCII protocol, this is the ASCII 
string "10", in the binary form, it is a byte with a value of 
10. 

= A numerical range from N to M. 

Equivalent to: N | N+l ] N+2 j ... j M-l j M 



Command Structures 

Packet 

PktSize 

Message 

Obj ID 

LongOb j ID 

ShortOb j ID 

Command 

C ommandTyp e 



= PktSize Message 

= UInt8 (size includes PktSize field) 

= Obj ID Command 

= LongOb j ID j ShortOb j ID 

= OString 

= UInt8 

= CommandType CommandData 
= UTnt8 



[Other commands might be added 
Command = 



to these : ] 
LongLocat i onCommand 
ShortLocat ionCommand 
StateCommand 
PropertyCommand 
PropertyRequestCommand 
CombinedCommand 
RoomChangeCommand 
Sessionlnit Command 
SessionExitCommand 
Appl i cat ionlni tCommand 
ApplicationExit Command 
DisappearActorCommand 
AppearActorCommand 
RegisterObj IdCommand 
Tel eportCommand 
TextCommand 
Obj ectlnf oCommand 
LaunchApp Command 
UnknownCommand 



Te 1 eport Command 
Location 

Ro omChange C ommand 
LongLocat ionCommand 
Di sappearActorCommand 
AppearActorCommand 
Location 

X, Y, Z, Direction 

StateCommand 

SetFlags, ClearFlags 

PropertyCommand 

PropertyReques tCommand 

S tat eReque s tCommand 

Property 

Variable ID 

ShortVariableld 

LongVariableld 

VariableValue 

ShortLocationCommand 

Del tax, DeltaY 

DeltaO 

CombinedCommand 

CombinedLocat ionCommand 

AbbrevLocCommand 

CombinedAppearCommand 

AbbrevAppearCommand 

CombinedDisappearCommand 

AbbrevDisappearCommand 

CombinedTeleport Command 

Abbr e vTe 1 eport Command 

[ for now : ] : , 
UnknownCombinedCommand , ; 



j WhisperCommand 

I StateRequestCommand 

= TBLEPORTCMD NewRoom ExitType EntryType 

= ROOMCHNGCMD NewRoom Location 

= LONGLOCCMD Location 

= DISAPPEARACTORCMD 

= APPEARACTORCMD NewRoom Location 

= X Y Z Direction 

= Slntl6 

= STATECMD SetFlags ClearFlags 
= UInt32 

= PROPCMD Property+ 

= PROPREQCMD VariablelD* 

= STATEREQCMD 

= VariablelD VariableValue 

= ShortVariableld | LongVariableld 

= UInt8 

= OString 

= String 

= SHORTLOCCMD DeltaX DeltaY DeltaO 
= SByte 

= SByte (plus 128 to -12 8 degrees) 

= CombinedLocationCommand 
CombinedAppearCommand 
CombinedTeleportCommand 
CombinedDisappearCommand 
UnknownCombinedCommand 

= SHORTLOCCMD AbbrevLocCommand+ 

= ShortObj ID DeltaX DeltaY DeltaO 

= APPEARACTORCMD AbbrevAppearCommand+ 

= ShortObj ID NewRoom Location 

= DISAPPEARACTORCMD AbbrevDisappearCommand+ 

= ShortObj ID 

= TELE PORTCMD AbbrevTeleportCommand+ 

= ShortObj ID NewRoom ExitType 
EntryType Location 

= 0. .3, 5. .10, 13. .17, 19. .255 



NewRoom 

ExitType , EntryType 
5 SessionlnitCommand 
SessionExitCommand 
ApplicationlnitCommand 

10 

ApplicationExit Command 
RegisterObj IdCommand 
1 5 TextCommand 

WhisperCommand 
LaunchApp Command 

20 

[for now:] 
UnknownCommand 

25 String 

StringSize 
field) 

3 0 Char 

UInt32 



3 5 Slnt32 



UlntlS 

4 0 SIntl6 

UInt8 
SByte 

45 

LONGLOCCMD 
STATECMD 
PROPCMD 
SHORTLOCCMD 

5 0 ROOMCHNGCMD 

SESSIONINITCMD 
SESSIONEXITCMD 
APPINITCMD 
APPEXITCMD 

5 5 PROPREQCMD 

DISAPPEARACTORCMD 
AP PEARACTORCMD 
REGOBJIDCMD 
TEXTCMD 

6 0 LAUNCHAPPCMD 

WHISPERCMD 
TELEPORTCMD 
S TATEREQCMD 

65 CLIENT = 1 ■ 

CO =2 54 

PO = 255 
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= UIntl6 i 
= UInt8 

= SESSIONINITCMD Property+ 

= SESSIONEXITCMD Property+ 

= APPINITCMD Proper ty+ 

= APPEXITCMD Property+ 

= REGOBJIDCMD String ShortObjID 

= TEXTCMD ObjID String 

= WHISPERCMD ObjID String 

= LAUNCHAPPCMD String 

= 0, 15, 20. .255 
= StringSize Char* 

= UInt8 (size of string EXCLUDING StringSize 

= C datatype char 

= 0. .4294967299 (32-bit unsigned) 

= -2147483650. .2147483649 
(32 -bit signed value) 

= 0.. 65535 (16-bit unsigned value) 

= -32768 . .32767 (16-bit signed value) 

= 0..255 (8-bit unsigned value) 

= -128.. 127 (8-bit signed value) 

= 1 
= 2 
= 3 
= 4 
= 5 
= 6 
= 7 
= 8 
= 9 
= 10 
= 11 
= 12 
= 13 
= 14 
= 16 
= 17 
= 18 
= 19 



Appendix B - Additional Control packet Examples 

B.l. State and Property Changes 

State changes change a string of boolean values . Either the 
Client or the Server can send these. Each object can have up to 32 
different state values. These are represented as bits in a bit string. 
If the Client wants to set bit 3 of the state variable of an object, 13 7, 
it sends the following: 

C>S 137 STATECMD 4 0 

In binary (given as hexadecimal) this is: 

C>S 89 02 00000004 00000000 

Properties take more possible values than states. Similar to 
state variables, properties are referenced in order. Variables may be 
represented as a predefined ID (counting from 1) or by an arbitrary 
string . 

Assuming that the Client has changed its local copy of a 
variable (with the tag 6) in object 23. It would send a command to the 
Server as follows : 

C>S 23 PROPCMD 6 "a new value" 

The variable ID is a predefined shorthand name for a variable 
name. These names are predefined and hardcoded into the Client. They 
generally can't be changed without changing the Client executable. An old 
Client that sees a variable ID it does not know must ignore the command. 

Some variables will always be defined, "bitmap" for example. 
These are defined in a fixed manner at the Client level. The Client will 
simply send these variable IDs to the Server which will transparently pass 
them on to other Clients . 

The currently defined variable IDs are : 

VAR_AP PNAME = 1 // Name of Application to run 
VAR_USERNAME = 2 // User's id. 

VAR_PROTOCOL = 3 // Version of protocol used by client (int) 

VAR_ERROR = 4 // Used in error returns to give error type 

VARJBITMAP = 5 // Filename of Bitmap 
VAR_PASSWORD = 6 // User's password 

VAR_ACTORS = 7 // Suggested # of actors to show client (N) 
VAR_UPDATETIME = 8 // Suggested update interval (* 1/10 sec.) 

VAR_CL I ENT = 9 // Version of the client software (int) 

The client can request the values for one or more properties with the 
PROPREQCMD : 

C>S "Fred" PROPREQCMD VAR_B I TMAP 

S>C "Fred" PROPCMD VAR_BITMAP "skull.bmp" 

A PROPREQCMD with no parameters will result in a PROPCMD being returned 
containing all the properties of the object the request was sent to. 

If a PROPREQCMD is made with a request for a property that doesn't exist, 
an empty PROPCMD will be returned. 

A STATEREQCMD requests the Server to respond with the current state. 



B.2. Beginning and Exiting Sessions 
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To begin a session, the Client requests a connection from the Server. 
After the connection has been established, the Client sends a 
SessionlnitCommand. 

The SessionlnitCommand should contain the User's textual name (preferably, 
this textual name is unique across all applications) and the version of 
the protocol to be used. For example, the User named "Bo" has established 
a connection and would now like to initiate a session. 

C>S CLIENT SESSIONINITCMD VARJJSERNAME "Bo" VAR_PROTOCOL "11" 

Currently defined variables for the SessionlnitCmd are: 

VAR_USERNAME The account name of the user 

VAR_PASSWORD User password (preferably a plain text string) 

VAR_PROTOCOL The protocol version (int) 

VAR_CL I ENT Version of the client software being used (int) 

Note that the protocol defines the value as a string, but the (int) 
comment is a constraint on the values that may be in the string. 

The Server will send an ack/nak indicating the success of the request. An 
ack will take the form: 

S>C CLIENT SESSIONINITCMD VAR_ERROR 0 
A nak will take the form: 

S>C CLIENT SESSIONINITCMD VAR_ERROR 1 
where the value of VAR_ERROR indicates the nature of the problem. 
Currently defined naks include: 

* ACK 0 It's OK 

* NAK__BAD_USER 1 User name already in use 

* NAK_MAX_ORD I NARY 2 Too many ordinary users 

* NAK_MAX_PR I OR I T Y 3 Too many priority users 

* NAK_BAD_WORLD 4 World doesn't exist 

* NAK_FATAL 5 Fatal error (e.g. can't instantiate user) 

* NAK_B AD_PROTO COL 6 Client running old or wrong protocol 

* NAK_BAD_CLIENTSW 7 Client running old, or wrong version 

* NAK_BAD_PASSWD 8 Wrong password for this user 

* NAK_CALL_BILLING 9 Access denied, call billing 

* NAK_TRY_SERVER 10 Try different server 

B.3. Beginning and Exiting Application 

To begin an application, the Client must have already 
established a session via the SessionlnitCommand. To begin an 
application, the Client sends an ApplicationlnitCommand specifying the 
desired application: 

C>S CLIENT APPINITCMD VAR_APPNAME " StarBright " 

The Server will respond with an ack/nak to this command using the same 
technique discussed under session initialization. 

B.4. Launching an Outside Application 

The Server may tell the Client to launch an outside 
application by sending the LaunchAppCommand to the Protocol Object. For 
example : 
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S>C PO LAUNCHAPPCMD "Proshare" 
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WHAT IS CLAIMED IS : 



1 1 . An apparatus for interaction between a 

2 plurality of users in a three-dimensional, computer-generated 

3 • graphical space, comprising: 

4 a plurality of client processes, wherein each client 

5 process is executed on a digital computer distinct from the 

6 digital computers executing others of the plurality of client 

7 processes; 

8 a central server process, executed by a server 

9 computer; 

10 a network coupling the server computer to the 

11 digital computers which execute the plurality of client 

12 processes, thereby coupling the plurality of client processes 

13 with the central server process; 

14 a plurality of user objects, executed as 

15 subprocesses of the central server process, wherein each of 

16 the plurality of user objects is associated with a user in the 

17 plurality of users; 

18 an environment database, accessible by each client 

19 process; 

20 means for communicating a position of a particular 

21 user in the three-dimensional, computer-generated graphical 

22 space from the particular user's client process to the other 

23 client processes via the central server process, the means for 

24 communicating programmed according to a protocol; 

25 means, on a digital computer executing the 

26 particular user's client process, for receiving positions of 

27 the users of the other client processes according to the 

28 protocol via the central server process; 

2 9 and means, on the digital computer executing the 

30 particular user's client process, for rendering a 

31 three-dimensional view from a viewpoint of the location of the 

32 particular user, the rendered view including at least one 

33 object from the environment database and, when other users are 

34 at locations viewable from the rendered viewpoint, including 

35 those other viewable users. 
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1 2. The apparatus of claim 1, wherein the 

2 environment database comprises a single central environment 

3 database. 

1 . 3. The apparatus of claim 1, wherein the 

2 environment database comprises one copy of the environment 

3 data at each of the plurality of client digital computers. 
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ABSTRACT OF THE DISCLOSURE 
SCALABLE VIRTUAL WORLD CHAT CLIENT- SERVER SYSTEM 

The present invention provides a highly scalable 
architecture for a three-dimensional graphical, multi-user, 
interactive virtual world system. In a preferred embodiment a 
plurality of users interact in the three-dimensional, 
computer-generated graphical space where each user executes a 
client process to view a virtual world from the perspective of 
that user. The virtual world shows avatars representing the 
other users who are neighbors of the user viewing the virtual 
word. In order that the view can be updated to reflect the 
motion of the remote user's avatars, motion information is 
transmitted to a central server -process which provides 
positions updates to client processes for neighbors of the 
user at that client process. The client process also uses an 
environment database to determine which background objects to 
render as well as to limit the movement of the user's avatar. 
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Office to Addressee" 
Assistant Cojh 
Washington. 



nee under 37 CFR §1.10 addressed to: 
? for Patents, 
r on ttovember 12. 1996 



PATENT 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In re application of : 

Dave Leahy, et al. 

Serial No. : NEW 

Filed: November 12, 1996 

For: SCALABLE VIRTUAL WORLD CHAT! 
CLIENT- SERVER SYSTEM 



Examiner: TBA 

Art Unit TBA 

DECLARATION OF PHILIP H. 
ALBERT IN SUPPORT OF PETITION 
FOR FILING PATENT APPLICATION 
UNDER 37 CFR §1.47 (b) : 
APPLICATION BY ASSIGNEE WHEN A 
JOINT INVENTOR REFUSES TO SIGN 
OR CANNOT BE FOUND 



Box: Patent Application 

Commissioner of Patents and Trademarks 

Washington, D.C. 20231 



Sir: 

I, Philip H. Albert, declare as follows. 

1. I 'am an associate in the law firm of Townsend and 
Townsend and Crew LLP and am one of the attorneys of record in 
the subject application. 

2. On November 7, 1996 and times before, I met 
personally and by telephone with Mr. Ardon requesting that he 
review the above -captioned patent application and sign a Rule 63 
declaration provided to him. 

3. Mr. Ardon refused to sign the declaration stating 
his belief that the claims did not recite patentable subject 
matter. 

4. After explaining to him the legal test for novelty 
and non-obviousness, I requested that Mr. Ardon provide an 
example of prior art which would render the claimed invention 
unpatentable, but he could not cite any. 
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5. Mr. Ardon is currently employed either as a 
consultant or an employee for one of Worlds' competitors. Worlds 
is concerned that Mr. Ardon may be basing his refusal to sign on 
a desire to prevent Worlds from obtaining a patent on an 
invention his current employer' may wish to exploit . 

6. I offered Mr. Ardon the opportunity to provide me 
with prior art references which I would submit in an Information 
Disclosure Statement, but he indicated that he would not take the 
time to search for prior art. 

7. To my knowledge, Mr. Ardon does not dispute that 
he was the developer of parts of the subject matter disclosed in 
the application and of parts of the claimed subject matter, only 
disputing the patentability of the claimed subject matter. 

8. In discussions about the patentability of jkhev 
claims, I asked Mr. Ardon to cite prior art which might cause the 
claims to be unpatentable. He cited a number of existing 
systems, such as "Habitat" developed by Compuserve, "Doom" . 
developed by id Software, the DIVE system used in Switzerland, 
and systems called "AMBER" and "DESCENT. " Mr. Ardon may have 
mentioned other systems, but I do not recall any beyond those in 
my notes. 

9. When I asked Mr. Ardon about specific limitations 
of the systems, he indicated that many of them were proprietary 
and he did not know about their inner workings. 

The undersigned declares further that all statements 
made herein of his own knowledge are true and that all statements 
made on information and belief are believed to be true and 
further that these statements are made with the knowledge that 
willful false statements and the like so made are punishable by 
fine or imprisonment, or both, under Section 1001 of Title 18 of 
the United States Code and that such willful false statements may 
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jeopardize the validity of the application or any patent . issuing 



TOWNS END and TOWNSEND and CREW LLP 
Two Embarcadero Center, 8th Floor 
San Francisco, CA 94111-3834 
Telephone: (415) 576-0200 
Fax: (415) 576-0300 



thereon. 



Respectfully submitted 



Date: 
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